Running TCP/IP in a Windows NT environment does not *by it self* open any
security holes (it is my protocol of choice), but some of the services and
applications that have become standard in the UNIX environment do.
FTP and Telnet are two prime examples of services that will send passwords
un-encrypted on the wire. With such services it is really the server that is
compromised, because this is where the revealed password can be used to gain
access. At this point, up to and including build 1057 (version 3.51) of Windows
NT, it can only be a server for FTP, with the exceptions mentioned previously.
The recommended configuration for a FTP server under NT is to *only* allow
anonymous access, this way no passwords for the NT machine will be divulged.
The real danger comes in a heterogeneous environment where users synchronize
passwords on their NT accounts and on some other system, such as a UNIX box,
and use unsecure services like Telnet and FTP. A local attacker can sniff
packets at the ethernet or IP level to capture the passwords, and a remote
attacker can possibly spoof a local router or host and have the IP packets
sent to a remote machine to be captured and analyzed. The best defense is to
educate users on secure password practices and create utilities to try and
test for bad habits.
If operating in a pure NT environment, refrain from using UNIX style services
and use the standard NT networking services. With the NT services you are
protected from the standard and not so standard password and IP spoofing
attacks. Even if an attacker spoofs a connection, they still have to deal
with the signed tokens servers and processes check.
There is one danger of information leakage with TCP/IP. If the host is multihomed, any application that binds to a port on one interface expecting to only send data on that network will be in for a big surprise. There is *no* guarantee that packets will
only be sent on the interface the port is bound to. If one NIC is on a private network and the other is on a public network, there could be problems[5]. This issue is apparently fixed in the build 1057 bits.
1.4 Closing Comments
Build 1057 of Windows NT has cleaned up a lot of the internals, and since
I have only had access to it for three days[4], I have not tested it out
*yet*. My words to live by are still: don't trust your users, don't think C2
means secure, and don't think that nobody can get in. Have fun!
Footnotes
1 There are third parties that supply telnet and r command daemons, but the
security issues involved with the current versions of the software are
tremendous (the documentation warns of this in some cases). It is possible for
an individual who is using the server locally to see what is being executed
remotely and enter commands to be executed as the remote user. This prompts
me to recommend against their use unless security is of NO concern.
Microsoft supplies an unsupported client/server remote command execution
utility (rcmdsvc.exe and rcmd.exe) with the Resource Kit that does not send
passwords in the clear, but I can not speak as to whether it is actually secure.
2 It could be possible to kill the process which has the database open.
This might leave the file wide open since the group everyone has full control.
3 It is possible to replace files in the system32 (or any other directory) by
doing a "copy trojan.exe \\target_machine\c$\%SYSTEMROOT%\system32\AT.EXE" if
the permissions are not set correctly.
4 Ah, but now I have access to thousands of them! and source! very LARGE.
5 I believe this will only manifest itself if the host thinks the destination
can be reached through the other interface. Probably rare, but I have seen it